The approach of a functional it analysis
The approach of a functional it analysis, as the first step in an ex ante evaluation, is based on Talbert’s exploration option described in the previous section. It starts with the creation of a list of all business processes that will be supported by the ERP systems that were included in the preselection. This list of processes is industry- or even company-specific. A good starting point for such a list is available in text books on accounting information systems, e.g. Romney & Steinbart [2000], or Von Meyenfeldt [2002].
Most ERP suppliers also provide process lists; these will normally only contain the processes that can be supported by their own ERP system and will therefore need to be supplemented. If a company has an internal controls or quality handbook, this may also be a good starting point.
After the creation of a list of processes, the exploration is carried out for each process that is supported by each of the preselected ERP systems. In Figure 6.1 the steps in the exploration are depicted graphically.
The first step is determining whether a perfect it exists between best practices supported by the ERP system and the current or desired business process. When a perfect it exists, process replication can be used for this process, which in general is possible without additional costs or risks.
When no perfect it exists, the contribution of the current business process to the organizational objectives has to be found out. If the current process does not offer a competitive advantage, is not crucial for the organization’s value proposition, and is not essential for other reasons, process modification is probably the best option. Process modification enables the organization to implement one of the best practices of the ERP system, which may result in benefits like cost savings or shorter time-to-market. Costs that need to be taken into account for the implementation of process modification are process design costs and employee training costs. Risks associated with process modifications are related to resistance to change, or to errors made due to limited familiarity with the new process or the new ERP system.
If on the other hand the current process does constitute a competitive advantage, is crucial for the current value proposition, or is essential in any other way, software modification is probably the best option for this process. Costs of software modification have to be taken into account, not only during the initial ERP implementation, but also during the later onward & upward phase of the ERP life cycle.
Risks associated with software modifications are budget overruns and late delivery of the modification.
A functional it analysis should be an integrated subproject of an ex ante evaluation. The participants of the project team are the decisive factor for the quality of the functional it analysis. In the project team, thorough knowledge of business processes, specialist knowledge of each ERP system in the preselection, and IT system development capability are essential.
Team members with expert knowledge on the current business processes cannot be missed, because they know the current situation. However, knowledge of the current processes is not sufficient. Team members also need to be able to analyze the potential improvements offered by best practices in the ERP system. Experienced users of the current systems are good candidates for the project team, as well as process analysts, quality specialists or operational auditors.
ERP specialists are also indispensible, because they know the best practices that can be offered by their ERP system. These specialists may in some cases be available in the own organization, but it is more likely that they will be hired from an implementation partner. This holds especially for small and medium sized businesses, where the required knowledge most likely is not available [Nufel & Debacker, 2007].
Finally, the contribution of IT system developers is essential. When for some processes the choice between process modification and software modification has to be made, system developers have to be able to estimate the effort required for the software modification.
Proper use of tools and methodologies can simplify the functional it analysis. The most important technique that is used for a functional it analysis is process modelling, for which several methodologies are available. ISAC, NIAM or traditional low charts have been used for decades [Von Meyenfeldt, 2002]; their common disadvantage is that they are labour-intensive.
Today, methodologies in combination with software are available that can model business processes in an intuitive and user-friendly way. An example of such a combination of methodology and software is DEMO [2014]. Less advanced voice automation software for drawing low charts is also widely available.
A software package that is specifically made for low charts is Visio, and other less complex software that is available for general presentations and drawings can also be used for drawing simple process models.
Some of the ERP systems can generate process models on the basis of the business logic that has been configured in them. This is very useful to document processes once they have been implemented. During the functional it analysis, this software is not very helpful, because it is clearly not yet known how the business logic will be configured in the ERP system. Some tools for process modelling of which the output can be exported and directly be used as input for the ERP configuration are available.